home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Belgian Amiga Club - ADF Collection
/
BS1 part 34.zip
/
BS1 part 34
/
FredFish PD 305.adf
/
Lhwarp
/
Changes.doc
< prev
next >
Wrap
Text File
|
1990-01-17
|
8KB
|
184 lines
LHWARP 1.20
A disk tracker for the Amiga
Written by Jonathan Forbes
Copyright © Xenomiga Technology, 1990
Version 1.01
Lhwarp 1.0 has a tiny bug, in that it won't output all of the extended
sector data. Lhwarp 1.01 has fixed this bug, but has caused itself to be
compatible with Lhwarp 1.0. Lhwarp 1.01 will produce smaller files than
Lhwarp 1.0, because it now stores the extended sector data as part of the
track data, for compression purposes.
The sudden update shouldn't be too much trouble, because Lhwarp 1.0 was
released less than 6 hours ago. Please delete the original Lhwarp 1.0 if
you have it, and use Lhwarp 1.01 in its place.
Version 1.02
Lhwarp 1.02 has implemented a 32-bit checksum, so that corrupted tracks can
be reported. Version 1.02 is fully backwards compatible with version 1.01.
Version 1.03
Lhwarp 1.03 uses only one track's worth of CHIP RAM (11k), for all its
reading and writing to disk. Data is copied from the CHIP RAM disk buffer
to FAST RAM (or, if you don't have FAST RAM, to some more CHIP RAM.) All
compression and decompression is now done in FAST RAM, if possible, so
compression time might possibly be smaller.
Versions 1.00, 1.01 and 1.02 crashed often, most probably due to lack of
stack space. Since my stack is permanently set to 90,000 bytes, I never
noticed, and neither did anyone else with a large stack.
Version 1.03 now allocates almost memory from Exec's free list, rather
than using large auto arrays (the latter being a very bad programming
practice anyway.) Stack size requirements have dropped by about 50k or so,
to hopefully around 3k, but you may wish to use more (say, 10k), just to be
safe.
Support for RAW unencoded MFM data will be implemented soon. An option to
append MFM data to an existing file will be provided.
If you have any suggestions, contact me soon, so that they will be
implemented quickly.
Version 1.10
- 1st January, 1990
Welcome to the 90's.
Lhwarp 1.10 is a significant upgrade; many of the compression/decompression
functions have now been rewritten in assembly language. Check the
accompanying "Lhwarp.doc" file for a timed comparison between new and old
versions (as well as to Lharc.)
The 32-bit checksum has been destroyed. Instead, a 32-bit CRC now protects
data integrity. As a result of having a large auto array containing the
32-bit CRC, as well as various other small additions, the required stack size
may have increased slightly; 10k is quite safe, however. Steps will be taken
to decrease stack size requirements.
File i/o now uses a 16k buffer if you have enough memory; if you don't, the
default buffer size is used (whatever it is; probably 512 bytes or so.)
Lhwarp will no longer archive sectors which are not used on the disk; the
disk's bit map is checked to see which sectors are allocated, and only those
are archived. This is much more efficient than Warp! To see for yourself,
try compressing a blank disk; it takes a matter of seconds.
The NOMAP option overrides the above, and ensures that every single sector
is compressed, regardless of whether or not it contains data. The NOMAP
command is to be used in place of READ, as a parameter.
Earlier versions of Lhwarp will be unable to decompress files produced by
Lhwarp 1.10. This cannot be helped. However, Lhwarp 1.10 can decompress
files produced by earlier versions. Whichever version of Lhwarp is used,
Lhwarp will inform you of which version the file was compressed with, and will
take appropriate action.
For additional specifications, please refer to "Lhwarp.doc", which has been
updated.
Version 1.11
- 2nd January, 1990
Another upgrade, one day later! Lhwarp 1.11 is a not as significant an
upgrade as 1.10. However, the large speed increase of 1.11 justified another
release.
In addition to the speed increase, Lhwarp now displays sectors as they are
archived or decompressed (just in case you were worried that Lhwarp has died
on you from its inactivity.) Sectors marked with an '.' will be archived,
while sectors marked with a '_' will not. Sectors will be marked with an 'o'
as they are archived.
Please refer to the updated documentation for more specifics.
Version 1.20
- 6th January, 1990
Lhwarp now supports two more compression algorithms; squeezing and
vaporising (the latter is the 14 bit version of UNIX Compress.) Both are much
faster than the LHARC Adapative Huffman Encoding algorithm (called
"freezing.") However, neither of them comes close to the compression ratio of
freezing.
Even so, the huge speed increase and reasonable compression rates should
appeal to those who are less concerned with compression efficiency, and more
concerned with speed.
Freezing remains the default compression mode. Using the -c switch will
cause the disk to be vaporised (not literally), while the -s switch will cause
the disk to be squeezed. The -b option will cause each individual track to be
either vaporised or squeezed, depending on which produces the smallest output.
The -q option will cause Lhwarp to use its fastest and most reasonable
algorithm on the disk. Currently, this is squeezing. Admittedly, vaporising
is faster, but vaporising often generates track output which is actually
larger than the track itself, and squeezing is almost as fast (certainly it's
faster than freezing.)
The most recommended option for speed, is the -b option, to select both
algorithms; compression time is only a few minutes longer than that of one of
the algorithms, and different algorithms sometimes work better for different
disks.
You cannot currently combine freezing with any other algorithm; this is for
your own benefit; I have yet to see freezing beaten by vaporising or squeezing
for any one track, ever! However, if you find that vaporising and squeezing
frequently do compress tracks more efficiently, please inform me.
To compress the NewTek DYNAMIC HI-RES demo disk:
Compression Size Time (approximate)
----------- -------- ------------------
Freezing 671630 20:00 minutes
Vaporising/Squeezing 770722 10:30 minutes
Squeezing 803714 07:30 minutes
Vaporising 869515 06:30 minutes
Warp program 796665 15:00 minutes
At this point in time, Lhwarp does not check to see if the output for a
track is larger than the input; this is why vaporising produced such a huge
file; many tracks compressed from 11k to 13k. This will be corrected in a
future version.
Lhwarp also supports viewing; you may see how Lhwarp has compressed a disk
(which tracks are contained in the file, which algorithm was used to compress
them, the source and destination lengths of each track, the number of sectors
compressed, and the sector map of each track.) The viewing option will also
display any attached text.
After any attached text is displayed, you must press return; this was
implemented so that the displaying of the boot block won't scroll the text off
the screen.
So there you have it; Lhwarp is faster and more efficent than Warp, and
Lhwarp is being updated; Warp isn't! All that's missing is the support for
raw track reads/writes, which will be implemented as soon as I find out how.
More compression algorithms would be greatly appreciated, however. I have
the source to "ZOO", but Compress (vaporising) is very similar. I have the
source to "ARC", but don't wish to be sued, so I won't use any algorithms from
there ("squeezing" was taken from Fred Fish disk #51, not ARC.) I also have
the source to "squash" and "splint", but am unable to get them to work. If
you have the C source to any decent compression algorithms, I'd appreciate it
greatly.
The ZIP algorithms would have been a good choice, now that PKZIP 1.0 is
here. However, not only do I not have the source to ZIP, ZIP is not free,
either; the author would probably want a large fee, or at least a fee for each
Lhwarp in use. So, ZIP has been thrown out of the window. LHARC 2.0 should
crush ZIP, anyway, so I'll just wait for that.
Thanks to the person in New York (?) who sent me PKZIP 1.0 (sorry, I can't
remember your name.)